為什麼會接觸到 OpenTelemetry，算是因為 Log 的追蹤關係，在後台上有兩三個 Spring boot 服務，因為在測試時可能因為一些原因導致錯誤出現，這時我們就要爬 Log 慢慢追蹤，但 Log 並沒有上下關係因此在追蹤上相對麻煩。也因為我剛入職不久，加上先前我參與了 Cloud Native Taiwan 的議程，剛好有人分享 Dapper 的原理，因此我提出分散式鏈路追蹤的想法。所以有極短時間在研究分散式鏈路追蹤剛好 OpenTelemetry 的規範也剛出不久也嘗試玩玩它。

官方說 OpenTelemetry is a collection of tools, APIs, and SDKs. You can use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) for analysis in order to understand your software's performance and behavior.

OpenTelemetry 是為了方便分析軟體性能與行為。

其支持的語言有

• JAVA
• C#
• Go
• javascript
• 等
  支持的組件
• MySQL
• Redis
• Django
• Grpc
• Kafka
• Jetty
• Akka
• RabbitMQ
• Spring
• Flask
• net/http
• gorilla/mux
• WSG
• JDBC
• PostgreSQL

其第一個穩定版本於 2021/02 發布，預計下半年完成 Metric 部分。

Opentelemtry 組件

• proto
  • 定義數據
• Specification
  • 有 API、SDK、Data
  • API: 用於生成數據。為每個數據源以及其他方面像是 baggage 和 propagators 定義。
  • SDK: 具有處理和導出功能的 API 實現。為每個數據源以及其他方面像是資源和配置定義。
  • 定義語義約定以提供與供應商無關的實現以及 OpenTelemetry 協議（OTLP）。
• Collector
  • 接收、處裡和導出數據
  • 支援發送到一個或多個開源或商業後端的開源可觀察性數據格式，例如 Jaeger、Prometheus 等
• Instrumentation Libraries
  • 蒐集不同組件的數據

API

可將 API 分成以下

1. A Tracer API
2. A Metrics API
3. A Context API
4. A set of semantic conventions

Trace

Trace API 會產生 Span，而 Span 會是該 Trace 中所做的操作，表示 Trace 中連續的操作。在 Span 中會給予一個 traceId，當中可為帶有時間戳的事件進行其它訊息的添加。
trace 代表了一個在系統中執行的過程。在 OpenTelemetry 標準下，trace 是一個有向無環圖（DAG）由多個 span 組成，每個 span 代表著 trace 中被命名和計時的連續性執行片段，Span 之間交互的邊被定義為父/子關係。

一個 tracer 過程中，每個 span 關係


        [Span A]  ←←←(the root span)
            |
     +------+------+
     |             |
 [Span B]      [Span C] ←←←(Span C 是 Span A 的子節點, ChildOf)
     |             |
 [Span D]      +---+-------+
               |           |
           [Span E]    [Span F] >>> [Span G] >>> [Span H]
                                       ↑
                                       ↑
                                       ↑
                         (Span G 在 Span F 後被調用, FollowsFrom)

時間軸的呈現

上面 tracer 與 span 時間軸關係

––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time

 [Span A···················································]
   [Span B··············································]
      [Span D··········································]
    [Span C········································]
         [Span E·······]        [Span F··] [Span G··] [Span H··]

Metric

Metric API 提供各式各樣類型的度量存取，像是 Counters、Observers。可在 Span 上下文中觀察當前 CPU 負載和 Disk 資訊等。可參考官方的資訊

Context

添加上下文的訊息，像是 W3C Trace Context, Zipkin B3 headers等。此外，此 API 允許追蹤 Span 如何在系統中傳播。隨著trace 從一個行程傳播到下一個行程，上下文也會更新。度量工具不論何時都可以訪問當前上下文。

Semantic conventions

在 OpenTelemetry API 中包含一組語義約定，當中包含了命名 Span、屬性以及錯誤關聯至 Span 的準則和規則。藉由在API 規範中對此進行編程，OpenTelemetry 可確保所有工具（無論作者或語言）都包含相同的語義訊息。

SDK

OpenTelemetry SDK 是 OpenTelemetry API 的實現。基本上由三個組件組成

• a Tracer
• a Meter
• and a shared Context layer that ties it all together

原則上 SDK 能夠滿足現有的需求，但這可以進行改動。

Collector

Receivers 會是數據的入口，它是 push 和 pull 模式，客戶端可以發送數據，或是以主動方式拉取數據。
Exporters 是出口，將數據丟至後端，同時也是 push 和 pull 模式
Processors 是一個管道的設置，是一個中間組間，可運行數據的處裡
Extensions 是其它的組件

Opentelemtry 架構

左邊和右邊是不一樣的佈署方式。

不過 Opentelemtry 因為尚未完全的成熟，因此只有針對 Trace 部分進行研究，明天會帶上 Jaeger 基本的構建和使用來玩玩 Trace，不過 Trace 對除錯的幫助滿大的因為它實現了上下文的關係在搭配日誌可以更有效率。

參考資源

• https://github.com/open-telemetry/opentelemetry-specification
• https://blog.newrelic.com/